The present invention relates generally to communications systems.
The Resource Reservation Protocol (RSVP) is a transport layer protocol which allows resources to be reserved across a network. The resources are generally reserved for a flow. Typically, a sender of a request will send an RSVP, or Path, message downstream to a receiver. The receiver will send an RSVP reservation request (RESV) message upstream to a sender of the request in response to the Path message. Some hops in a path between the receiver and the sender is arranged to create and maintain a reservation state that is associated with the resources reserved for data packets which are to be sent from the sender.
Typically, a RESV message specifies a bandwidth request which effectively indicates the amount of resources to be reserved for a flow. Each hop in a path that receives the RESV message ascertains whether it has sufficient resources to accommodate the bandwidth request. If a hop is able to accommodate the bandwidth request, the hop effectively reserves the appropriate amount of bandwidth for the flow. If the hop is unable to accommodate the bandwidth request, the hop generates an RSVP reservation error (RESVERR) message and sends the RESVERR message to the endpoint that is the source of the RESV message.
When an endpoint that is the source of the RESV message receives the RESVERR message, the endpoint may send a new RESV message which specifies a request for a smaller amount of bandwidth. As will be appreciated by those skilled in the art, some applications are only able to use certain bandwidths which match with the codecs supported by the applications. Hence, a request for a smaller amount of bandwith is generally a request for a smaller amount of bandwidth which matches the appropriate codes. In general, multiple RESV messages may be sent by an endpoint in an effort to reserve resources for a flow. By way of example, if a RESV message that requests eighty kilobytes per second (kbps) may not be accommodated, a subsequent RESV message that requests forty kbps may be sent. If the RESV message that request forty kbps also may not be accommodated, a subsequent RESV message that requests twenty kbps may be sent, and so forth. Typically, the amount of bandwidth within a RESV message substantially matches the amount of bandwidth within a chosen audio or video codec for a voice or video call, for example. An endpoint may support more than one codec, and may want to reserve the amount of bandwidth its preferred codec requires to operate within.
The sending and processing of multiple RESV messages may be relatively time consuming. As a result, it may sometimes not be possible for resources to be reserved for a flow in an efficient manner.